This invention relates to the distribution of software over a network. More particularly, this invention relates to the broadcasting of code and data, and updates thereto, to a plurality of subscribers.
In large scale networks such as the Internet, or Intranets within businesses, the distribution of software applications is often a manual and laborious process which requires the correct use of such program tools such as ftp, tar, compress, uudecode, and zip. The variety of platforms and tools, and the complexity of the installation procedures make this manner of distribution a complex and costly operation. Software installation is therefore frequently performed by specially trained system administrators rather than end-users.
The Internet has significantly accelerated the release schedule of applications significantly. Software is released more frequently and in smaller increments, and as a result many more installations have to be performed, resulting in more work for the system administrator. This multitude of releases can cause versioning problems when a new piece of installed software becomes incompatible with some previously installed software. As these updates occur more often, it is desirable to automate this update process.
A browser is a computer program for accessing the Internet via the World Wide Web, using the HTTP protocol. Browser plug-ins allow the user to extend the browser so that it can incorporate new functionality. Plug-ins are often very hard to install because they are platform dependent, and not secure because they are implemented in low level languages such as C or C++. To make plug-ins secure the browser needs to implement some form of authentication algorithm such as those based on the RSA algorithm.
The Java programming language and the introduction of Java applets has made it possible to run the same software program in a secure manner on many different platforms, thus enabling the wide distribution of such programs over a heterogeneous network such as the Internet. With Java applets it has also become possible to automatically launch small Java programs from a World Wide Web browser which eliminates a lot of the installation headache.
When Java applets are used as applications, the user is required to use a browser to navigate to the HTML page containing the desired applet. Once the applet is running it is usually constrained to the HTML page in which it is embedded, and the applet may be terminated prematurely when the user visits a new HTML page.
Further, Java applets have several restrictions which prevent them from scaling to larger applications. One problem is that the download times are too long because each Java class is loaded using a separate HTTP connection, and making each new connection often takes more time than the actual data transfer. Also, Java applets have to be reloaded from their source each time they are used, there is no mechanism for persistence other than HTTP caching. HTTP caching has the drawback that it is too low level, which causes versioning problems because it may mix old Java classes with newer Java classes. It is usually impossible to flush an applet from an HTTP cache, because it is not possible to know which files in the cache belong to the applet that needs to be flushed.
Because Java applets are reloaded for each use, and because they usually consist of many parts, they can significantly increase the number of server accesses and thus significantly increase the server load. As a result most high volume web-sites cannot afford to put Java applets on their HTML pages.
A Java applet generally cannot be used when the client computer is disconnected from the network. If the user wants to use an applet after disconnecting the network, it is first necessary to use all the features of the applet to populate the HTTP cache. However, if the user ventures into a previously unexplored part of the applet once disconnected, the applet will be unable to proceed and a fatal error will result. This is a major drawback of caching strategies because disconnected use is important for the next generation of portable Internet devices.
Another drawback of HTTP is that ongoing transactions can often be corrupted when new code and data is installed on the server. This is not a fatal problem when it happens to an HTML page, but corrupting a request can be catastrophic for an application. HTTP simply is not an appropriate mechanism for distributing code.
Some applications need the ability to monitor their use by the end-user. An example is advertisement tracking where it is necessary to keep an accurate count of how often an ad is shown. Currently advertisements are tracked by counting the number of hits on the HTML page containing the ad, which means that the page cannot be cached because this would affect the hit-rate. The page is therefore marked as not-cacheable, and the result is fewer cache hits and increased server load.
Personalized web-sites and personalized applications are also becoming very popular. Because of security constraints it is very hard to create a personalized applet. The reason is that the applet can't save state to the local disk and therefore all of the applet's persistent state must be stored in a database on the server, which further increases the server load.
What is needed is a way to distribute applications in a user-friendly, scaleable, secure, and seamless way, which enables the monitoring and personalization of applications, across a network such as the Internet.